2019/02/01

C#で座標変換するの、DotSpatial 使ったら超簡単 だった。(けどJGD2011未対応 。。。)

C# で緯度経度(WGS84)から、日本の測量座標系に変換するの、これまで C++用のproj4.dll を無理やり呼んでたのを、マネージドコードで完結させたかったので、初めてDotSpatial 使ってみた。
これが超簡単で感激したので、何年かぶりの書込み。。

まずインストールやけど、Nugetパッケージで取れるので、簡単。

Onlineのところで、検索窓に dotspatial で検索、
DotSpatial.Projections をインストール。これだけ。



C#のコードは

using DotSpatial.Projections;  //先頭で宣言
:
:
//値の準備
double[] lonlat = { 135.654321, 34.123456 };    //経度をセット、経度が先
double[] alt = {0d}; //高度はゼロ固定
ProjectionInfo wgs84 = ProjectionInfo.FromEpsgCode(4326);   //WGS84 変換元プロジェクション
ProjectionInfo jdg2000_6 = ProjectionInfo.FromEpsgCode(2448);  //測量座標系2000の6系のプロジェクション

//変換
DotSpatial.Projections.Reproject.ReprojectPoints(
                lonlat,
                alt,
                wgs84,
                jdg2000_6,
                0,
                1
);

//これでlonlatが書き換わって返ってくる
Console.Write(lonlat[0]);      //これは -31886.089481363244
Console.Write(lonlat[1]);       //これは -208112.27778280032

と超楽。この例では1点だけやけど、インテリセンスで出てくる引数を見てると、座標と高さを配列で与えると一括処理もできるみたい。






国土地理院の計算サイトで結果を比較してみると、誤差が出てくるのが0.1ミリのオーダーだったからまあよし。

ただ、東日本大震災でずれた地盤に対応したJGD2011に未対応みたい。(残念)

JGD2011の6系(EPSG 6674)を指定すると、

ProjectionInfo.FromEpsgCode(6674);



まんま、プロジェクションが無いエラーになる。

DotSpatial のサイトでソースを取ってきて、マスターと思われるGDALのファイルとDIFFしてみると、明らかにDotSpatialのファイルが古いみたいで、JGD2011だけじゃなくて6000番台あたりいろいろ無いのがわかる。

定義ファイルが入ってないだけみたいなので、一応Issueに上げておいた。。。

2019/2/2 追記

とりあえずForkして、JGD2011 が使えるもの を作っておいた。

2017/03/31

ジオイド+DEMのPNGタイルを作ってみた

国土地理院のDEM(標高)タイル。少し前はテキスト形式のタイルだけだったのがPNGタイルの配信が始まったと聞いたので使ってみました。

これは数値をピクセルのRBGの値にエンコードしたもので、テキストタイルよりかなり容量が小さい。
(出典:Web利用に適した標高ファイルフォーマットの考察と実装- 西岡芳晴・長津樹理、情報地質第26巻第4号、2015))

ただ、GPSで取れる高度は「楕円体高」なので、どちらかというとDEM(標高=海抜0mからの高さ)ではなくて、地表の楕円体高(= ジオイド高 + 標高)のタイルが欲しい。
国土地理院ではジオイドのデータもダウンロードできます。
(図の出展:国土地理院「ジオイドとは」より http://www.gsi.go.jp/buturisokuchi/geoid.html)

という訳で
  1. 地理院の標高PNGタイルをダウンロードする
  2. 各ピクセルに相当する場所のジオイド高を取得して、DEM値に加算する
  3. 再度PNGファイルにエンコードする
  4. クライアントに送る
というものをPHPで作ってみました。

例:
元の国土地理院のDEMファイル
 http://cyberjapandata.gsi.go.jp/xyz/dem_png/14/14361/6510.png
 

こちらがジオイド値を加算したもの。
 http://geoidtile.locapoint.com/ellipGndAlt.php?z=14&x=14361&y=6510

ちなみにジオイドのみ。この拡大レベルだとほとんど均一。
http://geoidtile.locapoint.com/ellipGndAlt.php?z=14&x=14361&y=6510&geoidonly=1

なお、ジオイドデータは地理院のファイル「gsigeo2011_ver2.asc」を使用、任意の緯度経度のジオイド値の計算は同資料に添付されている取り扱い説明書の「ジオイド高内挿計算方法」をつかいました。

ジオイドデータは19MBもあって都度読込むと大変遅いので、このデータから無効データを除外したものをmySQLに格納、必要なデータだけ呼び出すようにした。

PHPコードとデータのSQLダンプはこちら( https://github.com/naokiueda/ellipGndAlt )に置きましたので、ご興味のある方は自由に使ってください。

.htaccessにこんな感じでReWriteをかければ
RewriteRule ^/([0-9]+)/([0-9]+)/([0-9]+).png$ ellipGndAlt.php?z=$1&x=$2&y=$3
url...../{z}/{x}/{y}.png 形式の標準的なタイルURLになると思います。

確認用に呼び出しサンプルも作ってみた。
http://geoidtile.locapoint.com/sample.html

あまり考えずに「作ってみた」レベルなので死ぬほどレスポンスが悪いです。
またいつ消すか分からないので、ここで実装している
http://geoidtile.locapoint.com/ellipGndAlt.php?z={z}&x={x}&y={y}
をタイルソースとして恒久的に利用するのはご遠慮ください。




2016/12/13

GoogleMapsAPIベースのシステムにゼンリンの住宅地図(ZNET TOWN MAP)を組み合わせてみた

毎年アドベントカレンダーの時期に1つしか記事を書いてない気がします。。。1年あたり。。。。

飛び入り参加した FOSS4G アドベントカレンダー(その2)のエントリです。


今日と明日(2016年12月13、14)、芝公園のプリンスパークタワーで開催されているSalesForce World Tour Tokyo 2016 にサムライシステムとして出展してます。
SalesForce上で使えるカンタンな地図アプリとして「カスタマーコンパス」という製品を出してます。

「カスタマーコンパス」はGoogleMapsAPIをベースとして使っていて、OpenStreetMap地理院地図は標準で表示できるようになってます。


出展内容がマンネリ気味なので、今回は普段から問合せも多い『ゼンリンの住宅地図(ZNET TOWN API)』を表示できないか、デモ作ってみることにしました。
ゼンリンさんには展示会用限定でライセンスを頂きました。ありがとうございました!
なお、仕様は契約者以外非公開の機密情報なので、可能な範囲で書いています。

まず初めに、制約事項。

GoogleMapsAPIの利用規約で、GoogleMapsの地図タイルはGoogleMaps API経由以外で、タイルだけ取ってくることができません。

同様に、ゼンリンのZNET TOWN APIも、API経由以外のタイルの直接呼出しは規約上できません。

結局、システムの異なる二つの地図を両方とも出すしかない。


これがあるので、サブマップ(地図の中に小さな地図がある)タイプにするか、二つ並べてツインマップにするか、そういう方向性で考えないといけない。



そういえば、OpenLayersやLeafletといったAPIでGoogleMaps(地図タイル画像の直接呼出しがNG)使うトリックがいくつかあったなあ、、、とか、
y2blog『OpenLayers 3 とGoogle Mapsを組み合わせてみる』
OpenLayers e examples "Google Maps integration example"

実は昔、GoogleMapsとYahoo!地図を完全同期させたうえで、上下に重ね、マップ切り替えで上下のをスイッチすることで「なんちゃってシームレス」に表示できる「GYマップ」を作ったことあるなあ、、、とか。


そのあたりを参考に、いろいろ考えた末の方針が

1) 同サイズのGoogleMapsとゼンリン地図を用意する。
2) 位置、ズームレベルを同期させる。
3) GoogleMapsの背後にゼンリン地図を配置する。
4) 住宅地図を表示するときは、GooleMaps側で呼ぶタイルを完全に透明な「透過」タイルにして、住宅地図が透けて見えるようにする!!

ここで
  • ゼンリン住宅地図のDIVのZ-indexを -1 にセット
  • GoogleMapsで背後の壁紙になっている document.getElementById('map').firstChild のstyle.backgroundColor 属性を"transparent" にする

これで、GoogleMapsのコントロールやマーカーはそのまま前面に、背景だけ住宅地図になる。



ここで問題発生!!
マーカーの位置が合わないと思ったら、ゼンリンの住宅地図APIのズームレベル(縮尺)の取り方が、一般的な「地図タイル」の仕様とは異なる仕様でした!!

一般的というのはGoogleMapsや、OSMや、地理院のタイルのように、一つのタイルを4分割すると次のズームレベルに、という具合に縮尺比率が2倍、2倍に詳細になっていく仕様。X,とYの定義に若干の違いがあるけど、基本的なタイル地図の仕組みは同じなのでGoogleMapsでもOpenLayersでもLeafletでも(利用規約はともかく技術的には)同じように使える。

ところがゼンリンAPIは、2倍ずつではなく、ズームレベルに応じて縮尺がもう少し細かい。
横に並べて使うにはいいんだけど、背後に配置して「なんちゃってシームレス」にするには、ズームレベルがぴったりあってないと、マーカーの位置がずれる!!



ここでいろいろ試行錯誤して、GoogleMapsのズームレベル19(のみ)と、住宅地図のあるレベルの縮尺だけが偶然にもほぼ完全に一致することが判明。厳密には投影法が違うので、画面上見た目がほぼほぼ一致しているだけなんだけれど、実用上は十分。
ちなみに、他のズームレベル同士で縮尺が合うものは一つも無かった。

という訳で、カスタマーコンパスで「ゼンリン住宅地図」に切り替えた時は問答無用でGoogle側のズームレベル19に固定することでOK。


結果、ズームレベル19のとき限定ですが、一見GoogleMapsAPIにその地図を組み込んだの???と思うくらい「なんちゃってシームレス」な住宅地図を、利用規約にも違反せずに実装できました!!



タイルとGoogleMapの背景色を透明にすれば背景が透けて見えるので、背景を誰かの顔写真にしておいて、チェックインした位置情報のタイルだけ透明にすれば

『ジオ版 アタック25 その人物の名は!』

みたいなゲームできるな。。。。






      

2015/01/11

QGISでプラネタリウムを作れるか試してみた

きっかけ

天体観測関係の調べものをしてて、ふと思った。
天体の座標は「赤経」「赤緯」という座標で表すのですが、これは地球上の座標が緯度・経度で表されるのに似てます。緯度経度は
  • 緯度は赤道が0°で北がプラスで ±90°の範囲。
  • 経度はグリニッジ天文台を通る子午線が0°で東回りがプラスで±180°の範囲。

なのに対して赤経・赤緯は
  • 赤緯は「天の赤道」が0°で天の北極方向がプラスで ±90°の範囲。
  • 赤経は「春分点の方角」が0”時”で東回りがプラスで0時から24時まで。地上の経度が度・分・秒なのに対して時・分・秒で表す

では、赤経・赤緯を無理やり緯度・経度に読み替えると、天体の表示にGIS(地理情報システム)が使えるのでは??

という思い付きで、QGISでプラネタリウムを作ってみる!というネタです。


年末だったらFOSS4Gアドベントカレンダー2014に参加したいところやったのですが(^^;)、年が明けてしまったので単独エントリ(><)

QGIS


オープンソースGISの一つにQGISという初心者でも使いやすいGISソフトウェアがあるので、これを使うことにする。(QGISはここから無料でダウンロードできます



まずはデータ


星の座標データは「ヒッパルコス星表」から取ってきます。これはESA(ヨーロッパ宇宙機関)の人工衛星が作った全天の正確な星表で、NASAのサイトからダウンロードできます。

とりあえずこのサイトを参考にさせて頂いてダウンロードして、
赤緯→緯度
赤経→経度
にしてQGISでプロットしてるとこうなりました。。。。
この時点でちょっとやる気喪失。。。。。。。


とりあえず宇宙なのでバックグラウンドを黒にしてみる。

これでは訳が分からないので、都会の夜空程度、3等星並に絞ってみる。

ちなみに

  • 肉眼で見える限界は6等星
  • 1等星(以上)は21個
  • 一番明るいのはオオイヌ座のシリウス(-1.5等星)


赤で囲んだ所になんとなく見覚えのある配置が。。。拡大すると。。。。


こちら↓は本物のオリオン座


左右が・・・・逆!!


赤経・赤緯は「天球」に星を投影したものを「内側」から見てる。

これに対して、GISで使う座標は外側から「地球」を見たもの。

というわけで、必要なのは、



「地底人の視点」の投影! 

だけど、、、そんな投影はたぶん無いので、、、単純に経度を反転!

経度 *= -1 ;



というわけで、めでたくオリオン座完成!


星の色

ヒッパルコス衛星のデータは衛星画像のように5つの周波数で観測している。
RGBのデータが無い!!


で、星の色は理論的には表面温度によって決まる。
星表のデータ → 表面温度 → 色を算出

とできる(らしい)。

詳しく書いたサイトもあるけど、、、これを実装する気力もなかったので、「B-Vインデックス」という項目から、このサイトのデータを使って一番近い色にする。

一等星のサイズを大きくして色を確認。ちょっと違うけど、、、、、まあこんなもんかな。



星の明るさ

星の等級に応じて星の直径を変えてみたが、、、


昭和のプラネタリウムっぽい画に。。。。。。(シリウスがでかい)



もっとリアルな感じがいいので、工夫してみる。

大きさではなくて、暗さに応じて透過度を薄くしてみるも、カオス状態に。。。



そこで、、、
  • 大きさと透過度の両方で制御する。
  • 明るさの等級は5等級上がると1/100になる対数なので、ちゃんと計算して透過度と直径を設定
  • 明るい星は「光ってる感じ」を出すため、5等星までの明るい星はSVGアイコンにした 
  • あとは微調整

完成

これでかなり本物の星空っぽくなりました。
部屋を真っ暗にして、全画面で開くとそれっぽく見えます(^^)



これはオリオン座近辺、冬の大三角形とその周辺



これは全天




おまけ

上の全天画像を見て分かる通り、このままでは「メルカトル図法」になってしまってる。
高緯度地域を見てみると歪んでいる。
これはオリオン座(天の赤道付近なので歪んでない)、カシオペア座、北斗七星の線をプロットしたもの。
ごらんの通り、かなり歪んでる。北斗七星は「日付変更線(^^;)」を挟んでいるので、、、、




ここで、@picaosgeoさん、@kochizufanさん、@wata909さんにいろいろ教えて頂いて、投影法変換。
試行錯誤の末、正射図法が一番見た目のイメージに近いことがわかった。



これで北斗七星、カシオペアを描くと見た目に近くなりました。



今後


今後はGoogleEarthみたいな3D系のGISに入れてみて、ぐりぐり動くようにしてみたいなあ。


おわり

追記
緯度経度に直した座標と、等級、RGBに直した色データのCSVを置いときます。




2014/02/02

GoogleEarthで巨大なファイルごとパックしたKMZを開くと落ちた・・・

巨大な動画ごとKNZにする?

GoogleEarth上でアイコンクリックして、InfoWindowを開き、その中のリンククリックで動画を開く。

、、、というのをやろうとして、動画ごとサブフォルダにいれ、KMZファイルにパックしたところ。。。


、、開かない。。。落ちる。。。
マシンに依るみたいやけど、KMZを開いたとたんGoogleEarthが固まったり、GoogleEarthごと落ちたり。


いろいろ実験してみて分かったこと。

1.KMZに大きい動画とか一緒にパックすると、GoogleEarthで開いたらGoogleEarthごと落ちることがある。

推測ではあるけど、KMZを一旦メモリ上展開しようとして固まってるっぽい。メモリ容量の小さいPCでは落ちる。


仕方なく、KMZにせずZIPにパック。ローカルで解凍してKMLを直接開く。
それでGoogleEarthは落ちずに開きます。

が、さらに問題。
InfoWIndowを開いて、動画ファイルへのリンクをクリックすると
やっぱり固まる、落ちる。。。


ちなみに InfoWindow 内のリンクはこんな感じ。(「<」 を 全角の「<」で書いてます。。)
<description>
    <![CDATA[
        <a href="moviefodlder/mymovie1.mp3" >my movie
    ]]>
</description>

これも推測ではあるけど、どうやら GoogleEarth が InfoWindow を開くとき、Aタグのリンクがあればその先のコンテンツを先読みしようとして落ちているのかな、と考える。


なので、こんな回避策。

InfoWindowで開くのはローカルのHTMLファイルにする。こんな感じ。

<description>
    <![CDATA[
        <a href="wrapper.htm">my movie
    ]]>
</description>

で、このHTMLファイルは、目的の動画ファイルへリダイレクトする。
<html>
    <META HTTP-EQUIV="Refresh" CONTENT="0; URL=./moviefodlder/mymovie1.mp3" />
</html>

これで、GoogleEarthでローカルの巨大な動画ファイルが開きます。

ちなみに Google Earth のバージョンは 7.1.2.2041 です。違うバージョンでも同じでした。


まとめると

・巨大なファイルはKMZにパックしないほうがいい。
・InfoWindow内コンテンツに巨大な動画ファイルを直接リンクすると、先読みするのか、固まる/落ちる可能性がある。
・InfoWindow から一旦ローカルのHTMLにリンク、そのHTMLから動画ファイルにリダイレクトすると先読みを回避できる。

何か役にたてば。。。

2013/12/11

緯度経度を欲しいフォーマットに整形するjavascriptミニライブラリ GeoFormat.js を作りました

最近ほとんど更新してなかったブログ、最終投稿から1年経ってました。。。。

FOSS4Gアドベントカレンダー2013で、2013/12/11 の担当になったので、記事を書くことになりました。

といっても、普段GISをほとんど使わない身としては、身近なFOSS4Gといえば99%OpenLayersのみ。。。

アドベントカレンダーの参加者の皆さんが、非常に濃い内容の記事を日々アップされている(プレッシャー!!)ので、いきなりバトンを落としそうになっていますが、、、、
無理なものは無理。今日はお気軽な内容で一息ついてください。まあ、忘年会シーズンの休肝日みたいなものです(苦笑)

さて、先日のジオメディアサミットにて地図ドア(bit.ly/chizudoor)というガジェット(オモチャ)を発表しました。これは、
の15のWEBサービス間で、地図の中心を維持しつつ、別のWebサービスを開く、というものです。
WEB地図サービス間をシームレスに自由に行き来するドア、「地図ドア」です。
おまけで、KML出力でGoogleEarthにも飛べるようになってます。
ブラウザ拡張機能を使っていて、各社サービス内のjavascriptを勝手にハックして現在表示中の地図中心座標を取得し、行き先URLのパラメータに緯度経度を渡してページを開いてます。
勝手にハックしているので、(各社のサービス更新などによて)いつ動かなくなるか分からないのがイタイところです。




さて、これを作ってる時もそうですが、緯度経度を各社のURLを整形する時にいつも思うのが、各社緯度経度のフォーマットが非常にバラバラなこと。まあ、決まりがないので自由といえば自由なのですが。
各社が利用している「緯度経度のフォーマット」を整理すると以下の通りとなりました。(ちなみに2005年にここギコ!さんと作った「MapSurfer」というアプリのときに調べた結果と並べてみた。)
フォーマット
2006年
現在
度(小数点付の実数)
GoogleMaps
MSN Live!
MapQuest
GoogleMaps
Bing Map
excite
BIGLOBE
地理院地図
OpenStreetMap
Mapion(
日本測地系)
LiveDoor
地図(日本測地系)
方位文字(n/e/w/s)
+度(整数)
+分(整数)
+秒(小数点付実数)
MapFan(日本測地系)
Its-mo Guide(
日本測地系)
Goo
地図(日本測地系)
ライブドア地図(日本測地系)
Goo地図(日本測地系)
MapFan(
日本測地系)
度(符号付整数)
+分(整数)
+秒(小数点付実数)
Mapion/MapionBB(日本測地系)
NAVITIME(
日本測地系)
ALPS
ラボ(日本測地系)
Yahoo!Map(
日本測地系)
MSN
マップ(日本測地系)
NAVITIME(日本測地系)
秒(少数付実数)
ちず丸(日本測地系)
 
ミリ秒(整数)
 
Mapple
いつもNAVI

2006年と比べると傾向として、
  • 度/分/秒の分離型の減って、度の実数を使うところが増えた
  • 日本測地系を使うところが減った
感じですね。




さて、このフォーマット変換、変換そのものは大したことない式ですが、このようなアプリを作るにはいちいち各社のフォーマットに整形しないといけないので、非常に面倒くさい。使い勝手のよいフォーマット機能もなさそう。特にJavaScriptだと分を算出しようとしても
35.12345-35 = 0.12344999999999828(おいおい!)
とかになったりして、誤差が出てしまったりするし。

というわけで、需要はあまり無いと思うけど、緯度経度用のフォーマット出力用ミニライブラリ GeoFormat.jp を作ってみました。ダウンロードはこちら


使い方
① 緯度経度を引数にインスタンスを作成。引数は緯度、経度の順で、「度」「度、分」「度、分、秒」のいずれかで指定する
例:
var gf = new GeoFormat(35.12345, 135.12345);
var gf = new GeoFormat(35, 7.407, 135, 7.407);
var gf = new GeoFormat(35, 7, 24.42, 135, 7, 24.42);


②インスタンスは二つのメンバオブジェクトを持つ
lat
lon

③このメンバオブジェクトはそれぞれ以下のメンバ関数を持ってます。
すべてフォーマット出力用で文字列を返します。(例 -135度12分46.789秒)
deg(format_formula) //角度を度で表したもの。符号付実数 -135.2129969444444
min(format_formula) //分以下の値。実数。常にプラス 12.77981666666667
sec(format_formula) //秒以下の値。実数。常にプラス 46.789
msec(format_formula) //1秒未満のミリ秒を返す。常にプラス 7890.0000
fullmin(format_formula) //角度を分で表したもの。符号付実数 -8112.779816666664
fullsec(format_formula) //角度を秒で表したもの。符号付実数 486766.7889999998
fullmsec(format_formula)//角度をミリ秒で表したもの。符号付実数 486766788.9999998
rad(format_formula) //角度をラジアンで表したもの。プラスの実数 3.9232733190099993238303058379106

フォーマット書式はC言語系のprintfの書式をベースに簡素化したものにしました
型指定
%d 符号付整数で表示
%u 符号なし整数で表示
%f 符号付小数点で表示

オプション
"+"  正のときでも「+」を表示する
"a" aspect:符号の代わりに n/s(緯度のとき)、e/w(経度のとき)を数字の前につける ※これはC言語系printf書式にはない独自拡張
"A" Aspect:符号の代わりに N/S(緯度のとき)、E/W(経度のとき)を数字の前につける ※これはC言語系printf書式にはない独自拡張
" "(スペース)幅指定ありで桁数が足りないとき、スペースで埋める
"0"(スペース)幅指定ありで桁数が足りないとき、ゼロで埋める


幅指定 Nまたは N.N 形式で指定
例 35.12345(緯度)
"%04d"   0035
"%+04d"   +035
"%04.3f"   0035.123
"%.3f" 35.123
"%a.3f" n35.123
"%A04.3f" N035.123


これを使うと、フォーマットが楽になります。
例えば、35.12345,135.12345(35°7分24.42秒、135°7分24.42秒、) の座標を使うとして
    var gf = new GeoFormat(35.12345,135.12345);
としておけば、

GoogleMapsのURL 
www.google.co.jp/maps?q=35.12345,135.12345

"www.google.co.jp/maps?q="+gf.lat.deg("%f")+","+gf.lon.deg("%f")
と書けば出力できます。

Goo地図の場合
link.maps.goo.ne.jp/map.php?MAP=E135.7.24.42N35.7.24.42&ZM=9

"link.maps.goo.ne.jp/map.php?MAP=" +gf.lon.deg("%Ad")+"."+gf.lon.min("%d")+"."+gf.lon.sec("%f")
+gf.lat.deg("%Ad")+"."+gf.lat.min("%d")+"."+gf.lat.sec("%f")+"&ZM=9"
と書けば出力できます。

いつもNAVIの場合、mSEC単位なので
www.its-mo.com/z-486444420-126444420-15.htm

"www.its-mo.com/z-"+gf.lon.msec("%d")+"-"+gf.lat.msec("%d")+"-15.htm"
と書けば出力できます。


100%自分用に作ったものですが、よかったら使ってください!
もちろんオープンソース!!
/*

  GeoFormat.js
 
  version 1.0
  Dec.11.2013
 
  Copyright (c) 2013 by Naoki Ueda
  Published under the 2-clause BSD license.
  See http://openlayers.org/dev/license.txt for the full text of the license
 
*/

というところでお茶を濁して、アドベントカレンダーの記事とさせて頂きます。。。


2012/11/30

ジオメディアサミットというイベントは進化したかもしれない。(第10回ジオメディア・サミットに行ってきた)


昨日の2012/11/29(木)に開催された、第10回ジオメディアサミット「地域メディアの可能性」に行ってきた。

昨日のジオメディアサミットはすごくよかった。なんか、これまでのものとちょっと異なっていた。

感覚的な表現で申し訳ないけど、これまでのGMSは(メインは)ジオ+(サブ)テーマ、でテーマが毎回違うという感じやった。ジオの技術をどう使うか、どう使われているか、どうビジネスにつなげるか、、という感じの頭の使い方をしていた。そしてサミット中にいろいろアイデアが出てくるような。


けど、今回は「地域」というかなり大きなくくりの緩い縛りで、メインがいろんなジャンルに渡っていた。そしてその中にそれぞれ(サブで)ジオの要素がある、という感じ。そして、感覚的に一番違うのは、情報やアイデアが多すぎて、ほとんど情報爆発のような感じで、いろんなジャンル、いろんなアイデアの素、いろんな人々、とにかくダーッと多種多様のエネルギーが頭に入ってきて、いい意味で整理しきれずに混沌としてる。

昨日の事例紹介にあった各種イベントもそうだけど、この混沌からインスピレーションを得てアイデアに落とし込む人、アイデアを実行に移す人、それをテクノロジーでサポートする人、応援する人、
等々がうまく出会うと、また一つ何かが生まれてくるが、そういう人達が出会う場にもなっている。

ジオメディアサミットというイベントは進化したかもしれない。

でもその進化を支えているのは「人」で、関さんをはじめとする運営メンバー一人ひとりが、他のいろんなコミュニティのハブであり、コミュニティ同士をつなぐコネクターになっているという点も見逃せない。

ジオメディアサミット関西も、この進化についていかないと!!! 
(今回のGMSを越えるGMSを関西でやろうや!!協力者求む!!)

2012/10/04

GeoHashが米国特許6,552,670(通称 BINGEO)に引っかかってるかもしれない

「元ここギコ!」さんのFacebook書込みに触発されて、GeoHash の仕様が掲載されているWikipediaのページを久しぶりにじっくり見てみた。

GeoHashとは、緯度経度の位置情報を表すコードで、短い文字列で場所を表すことができるため、Twitterのジオタグなどに使われてることが多い。

この種の位置情報コードは、現在私が把握しているだけで全世界に24種類ある。私自身も位置情報コードを発明して特許を取ったことがある。(このブログのタイトル「ロカポ」はその位置情報コードの名前。現在はロカポv2にあたる LP-Address を無償公開)。それ以来、位置情報コードの情報は常に収集していて、「位置情報コード百科 - GEOCODE Encyclopedia」というドキュメントをつくったり、大学で論文として発表したりしている。

で、本題に戻ると、GeoHashのエンコーディングの手順が、アメリカ特許の US6,552,670 (「Location encoder」 by Sundaravel; Vale (Framingham, MA), Paul; Benjamin J. (Winchester, MA) 、Switchboard Incorporated (Westborough, MA)、2001年出願、2003年成立)に記述されている内容とほぼ同じ、ということに気がついた。

この特許は「BINGEO」という名称で、位置情報をバイナリコード化する、という特許だ。

ものすごく簡略化していうと、BINGEOはあるエリアを上下左右に四分割し、0,1,2,3,と番号を振る。それを 00,01,10,11というように2桁の2進数で表す。分割されたエリアはさらに四分割し、それぞれに2桁の2進数が追加される。元が00の領域を分割すれば、 0000,0001,0010,0011に分割される。こうして、必要な精度まで分割していく。つまり、2ビットを1つの単位をして、エリアがどんどん四分割されていくことになる。結果的にできあがった2進数は緯度方向を表すビットと、経度方向を表すビットが交互に並ぶことになる。スイッチボードという会社の発明で、位置情報を2進数にしておいて論理演算する仕組みまで明細にある。


さて、GeoHash。

こちらは緯度と経度をそれぞれ別々に二分割、二分割として0か1を割り当てる。ここまでは良い。これを「前方一致検索」で使いたいという意図と思うが、偶数ビットを経度、基数ビットが緯度となるように、上位桁から交互に並べていく。組み合わせてできあがった二進数文字列(長さは倍になっている)は、細かい差異を無視すれば、BINGEOで作ったものと全く同じものとなってしまう。

GeoHashはこれをさらに5ビットの倍数になるような精度に調整し、5ビットごとに0-31の値にし、それに文字を割り当てている。違うのはこの最後の部分だけ。


BINGEOは「最適な使用例」に出てくるのは前述したコードだが、特許明細の請求項を見てみると請求項が93もあり、ありとあらゆる派生物まで範囲に入れようとしているように見える。
メインの請求項はこれ。US-Patentの簡易検索で「BINGEO 」のキーワードで一発で出てくる。
What is claimed is:
1. A method of forming a binary representation of geographic information based on a coordinate system, the method comprising, relating the geographic information to the coordinate system, providing a hierarchical segmentation scheme to create subdivisions based on the geographic information, assigning a binary code to the subdivisions, determining a level of the hierarchical scheme to provide a desired precision for the binary representation, forming the binary representation based on the assigned binary codes and the desired precision.



つまり、請求項をめちゃめちゃ広く取っている上に、従属項も多岐に渡るので、けっこう多くの「位置情報をコード化したもの」が引っかかる可能性がある。先ほど、ここギコ!さんに「MicrosoftのQuadKeyは4進数を使っているのでぎりぎりセーフかも」と言ったのですが、これも結構微妙かも。

GeoHash自体はパブリックドメインとなっていて、利用は自由だ。ただ、万一GeoHashの計算そのものがこの特許に触れていると、(米国で、と前置きになるが)GepHashを使って「業を営む」際には特許権侵害のリスクがあると思う。
私では専門的な判断は下せないが、調べた限りではかなりグレーっぽい。
どなたか弁理士の先生か、知財の専門家の方にご意見伺いたいところです。

GeoHashは位置情報コードの中では、かなり広く使われている方なので、もし権利関係で問題あれば影響大きそうです。。。



最後に少し宣伝。
さて、位置情報コードは前述したようにいろいろなものがあり、用途によって何が最適かは全然違ってきます。コードが必要でどんなコードが最適か迷ったときは是非ご相談ください。
こんなマニアックなお金にならない研究をしてるのは私しか居ないです(笑)
独自のコード開発もしています。
・商品属性など緯度経度以外の情報もコードに含めたい
・緯度経度を暗号化したいがコード化したまま空間検索もしたい
・緯度経度を使うと他社の特許に引っかかるのでコードを使って回避したい
など、なんでも気軽にご相談ください。


2011/03/30

ロカポがアメリカで特許を取得しました。

このたびの東北地方太平洋沖地震で亡くなられた方々のご冥福をお祈り申し上げますとともに、被害に遭われた方々とそのご家族、関係者の皆様に、心よりお見舞い申し上げます

有限会社ロケージング
代表取締役
上田 直生
-------------------------------------------------------------------------------------------------

ロカポが米国での特許を取得しました。
特許審査が通った旨は昨年末に米国の弁理士事務所より連絡を受けていたのですが、正式に書類が発行されたものが届きました。





















ロカポ(正式名称「LocaPoint」、現在はLocaPoint Version2を「LP-Address」の名称で展開中」)は弊社が開発した位置情報コード(緯度経度と対応するコード)で、「読み間違えにくい」ことを最大の目的に開発されています。その本来の目的は、災害や遭難時のSearch and Rescue(捜索救助活動)などの非常時において、救助される方、救助する方が緯度経度を伝える際に「人為ミス(言い間違い、読み間違い、聞き間違い)」で致命的な結果となることを抑止することにありました。

開発当初に想定していたのはダイビングやサーフィン等の漂流事故で、GPSとイリジウム衛星のSMS(ショートメッセージ)等、なんらかの連絡手段さえあれば、間違いなく自分の場所を伝え、救難してもらえるようにすることが目的でした。

今思えば、ロカポ開発中にスマトラ島沖地震の津波が発生し、沖へ流されて亡くなられ方が多くおられたと聞き、ロカポがもし災害時に利用されるとして、人為ミスによる二次被害を防ぐため、より間違いにくいものにすることに徹底的にこだわったのを思い出します。

ロカポは、改良型のロカポ2(LP-Address)の開発までは精力的に行っていたのですが、最近は多忙でLP-Addressを利用しやすくするツール類(せめてロカポv1周辺のツール類相当に充実させる)などの開発が遅れておりました。

今回、書類が米国から送られてきた日付がMAR 11 2011. 東北地方太平洋沖地震の日です。
サイエンス偏重で神秘的なものは「人の縁」以外はほとんど信じない私ですが、、、、偶然とはいえ、自分にもっと力があって、ロカポがもっと世間に普及していたら、災害直後の救助や、今後の復興に少しでも役に立っていたのだろうか、、、、これは「もっとロカポの普及に力を入れろ」ということなのだろうか、、、と思わざるを得ません。


ロカポの使用フィールドとしては、他に目印の無い海や砂漠を想定していまして、住所やふんだんにランドマークがある市街地ではロカポを使うメリットはあまり思い浮かびませんでした。
しかし、全く想定していない事でしたが、津波の被害跡のように、どこが道路だったかすら分からないような状態では、住所やランドマークが全く使えないので、復興当初はGPSによる緯度経度や測量座標などの座標系を用いる以外に場所を管理する方法はないのではないでしょうか。その際、測量や建築は正確な座標が必要ですが、当面の物流や待ち合わせ、場所の指定などにロカポ(もしくは類する位置情報コード)が非常に役に立つのではないかと思っています。

ロカポはWGS84測地系の緯度経度と1:1で対応しており、簡単な数式一つで相互に変換できます。特に昨年公開したロカポ2(LP-Address)は緯度経度共にロカポ1単位が0.00001度になっており、既存の緯度経度ベースのシステムとの親和性も非常に優れています。

既にロカポの日本国内特許は商用/非商用にかかわらずライセンスフリーとして開放しており、特許の更新も行っておりません。
ロカポ/LP-Addressが今回の震災の復興に、さらには将来発生するかもしれない災害時の被害拡大防止や復興に、少しでもお役に立てれば幸いと考えております。


2010/11/11

ジオメディアサミット西日本 ミニイベント 大盛況でした。どうもありがとうございました。

(報告が大変遅くなってしまいました。すみません。

2010年11月)6日、ジオメディアサミット西日本のミニイベントが開催されました。
第一回ジオメディアサミット関西、第二回ジオメディアサミット西日本(改題)と同じく、FOSS4G-Osaka内の枠を借りてのミニイベントです。直前のFOSS4G-Tokyoでは、ジオメディアサミットからは「ジオガールズサミット featuring ジオドル」ということでジオドルのみなさんが大活躍されていました。
今回も大ライトニングトーク大会ということで、なんと12本のLTを怒涛のように行いました。
(ハッシュタグは#GMS2010 です。)

今回FOSS4GさんがUStreamされていたので、同じチャンネルでジオメディアサミットも流していただきました。ジオメディアサミットのLT以外にも多くの楽しいトークがあります。ぜひこちらもご覧ください。

さて、以下、ミニイベントのライトニングトークの様子です。

1.「自作GPSロガーの実装」たなかとしひさ様 (lilo、OpenStreetMap Japa)
http://www.ustream.tv/recorded/10663442

まずはOpenStreetMapのメンバーでもあるたなかさん、OSMにちょうどいいロガーを作ろう!ということでGPSロガーをなんとハードウェアから作られています。
ハードウェアのライトニングトークはジオメディアサミットではおそらく初めてですね。
※はじめは私のグダグダ挨拶です。たなかとしひささんのパートは動画の9分くらいの所から


2.「誰でもできるMolaMolaの作り方」古橋大地様(マップコンシェルジュ株式会社)&花菜様(プチ・ジオドル)
http://www.ustream.tv/recorded/10663797

ジオメディアとFOSS4Gの両方で活躍されている古橋さん。FOSS4GジャパンのオリジナルキャラクターであるMolaMolaが生まれた経緯やデザインへのこだわり等の話をしていただきました。
3歳の娘さん花菜ちゃんもプチ・ジオドルとして参加!ジオコミュニティの平均年齢を一気に引き下げてくれました!


3.「日本一のバス案内システムが鳥取にあった:バスネットの技術と挑戦」伊藤様(鳥取大学工学部 知能情報工学科)
http://www.ustream.tv/recorded/10663955

最近鳥取大学に移られたばかりの伊藤さん。なんと鳥取で実際に稼働しているバスの案内システム。話を聞いてるとNAVITIMEよりもすごいかも!と思いました。これは聞く価値あります。そしていろんな交通機関がぜひ追随してほしいですね。ジオリパブリックさんのOpenVRPが直接応用できそうですね。


4.「位置表現抽出・管理サービスLocoSticker」川北泰広 様(沖電気工業株式会社)
http://www.ustream.tv/recorded/10664071

ジオメディアではすっかりおなじみ、沖電気さんによるLockStickerの紹介。いつもは福居さんが話されていることが多いのですが、今回は川北さんのによる発表。
「ジオどす」を使って頂いてることもアピールして頂きました。気を使って頂いてありがとうございます!


5.「青六会について~異業種交流会」 玉置 様(青六会主催)
http://www.ustream.tv/recorded/10664197

ジオメディアサミット西日本がジオメディア(≒LBS)とGIS(のうちのFOSS)の接点だとすると、何年も前からGISとITS(Intelligent Transportation System、カーナビとかETCとかVICSとか)の両業界の接点となるような懇親会を主催されている玉置さんより、その会のご紹介。


6.「42本のFOSS4Gが使えるOSGeo-Live DVDの日本語化参加者募集中」 嘉山様(FOSS4G)
※嘉山さんのパートのUStreamがありません!!
またしても参加した方しか見れなかった??伝説のライトニングトークになってしまいました。

FOSS4Gの嘉山さん。過去のライトニングトークで大爆笑を巻き起こしたライトニングトークの達人が登場、42本のソフトが入っているOSGeo-LIVEのDVDの紹介とメンバー募集。
5分の内の残り2分で42本のFOSSを全部紹介するという荒業!さすが!


7.「レーザースキャナによる3D計測」デベロソリューションズ様(の代理で上田)
http://www.ustream.tv/recorded/10664655

休憩をはさんで、測量業界のベンチャー、デベロソリューションズさんの発表。トークをお願いしていた社長さんのアメリカ出張が伸びて、代理の営業の方も風邪でダウンで、回り回ってトークを依頼した私にトークの依頼が回ってきた!?というわけで、私が代理で発表。


8.「ZOOってどうよ」林様(応用技術株式会社 ZOO伝道師)
http://www.ustream.tv/recorded/10664795

FOSS4Gではおなじみの応用技術の林さんによる、WebProcessingServiceのZOOの発表。
WPSとは、本来GISのソフトをインストールしないとできないような高度なGISの処理を、WEBサービスとして提供する技術のこと。これからの注目技術です。


9.「iPhoneでGPSロガーを作ってみました」関 様(ジオリパブリック)
ジオメディアサミットの主催、シリウスラボの関さん。今回はジオリパブリックの関さんとして、iPhoneをGPSロガーにした開発のお話。
http://www.ustream.tv/recorded/10664900


10.「簡便な延焼シミュレーションシステムの構築を目指して」河波秀美様(和歌山工業高等専門学校 環境都市工学科 辻原研究室(地震工学))
河波さんは和歌山高専の5年生で卒業研究についての発表。なんと(プチ・ジオドルの花菜ちゃんを除けば・・)ジオメディア史上最年少プレゼンターです。ものすごーく緊張されてましたが、プレゼンは堂々たるもので中身もすばらしかったです。
http://www.ustream.tv/recorded/10665041



11.「Yahoo! Open Local Platform(YOLP)」 池田 邦栄 様(ヤフージャパン株式会社)
次もおなじみヤフーさんによります、YOLPのご紹介。毎回発表されるごとに機能が増えていってますね。
http://www.ustream.tv/recorded/10665228



12.「場所を見張ってお知らせするGeoNotifier」福居毅至 様
いつもは沖電気でLocoStickerの発表をされている福居さん。今回は個人で作ったサービス「GeoNotifier」をご紹介頂きました。いま流行のGeoHexを使ったアプリです。
http://www.ustream.tv/recorded/10665340



今回は直前の告知にも関わらず、昨年以上の集客ができました。この分野の盛り上がりを感じますね。

このあとは懇親会。懇親会は28名とちょっと人数が少なめでしたが、その分濃い交流ができたと思います。私は写真を撮っていなかったので、どなたか写真をお持ちであればこのブログ掲載用にください。


さて、来る2010年12月17日には、第三回ジオメディアサミット西日本を京都にて開催いたします。
今話題のチェックイン系サービスのプロバイダーに集まって頂き、「盛り上がるチェックイン・サービス」というテーマでのパネルディスカッションを予定しています。
もちろん、ライトニングトーク+懇親会も行います。
明日の夜に正式に告知予定です。

ぜひお楽しみに。

ジオメディアサミットにご参加いただきました皆様、講演者の皆様、および応援、ご支援いただいた皆様、どうもありがとうございました!!